1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer-readable code for improving the manageability and usability of a Java environment.
2. Description of the Related Art
Java is a robust, portable object-oriented programming language developed by Sun Microsystems, Inc., and which is gaining wide acceptance for writing code for the Internet and World Wide Web. While compilers for most programming languages generate code for a particular operating environment, Java enables writing programs using a xe2x80x9cwrite once, run anywherexe2x80x9d paradigm. (xe2x80x9cJavaxe2x80x9d and xe2x80x9cWrite Once, Run Anywherexe2x80x9d are trademarks of Sun Microsystems, Inc.)
Java attains its portability through use of a specially-designed virtual machine (xe2x80x9cVMxe2x80x9d). This virtual machine is also referred to as a xe2x80x9cJava Virtual Machinexe2x80x9d, or xe2x80x9cJVMxe2x80x9d. The virtual machine enables isolating the details of the underlying hardware from the compiler used to compile the Java programming instructions. Those details are supplied by the implementation of the virtual machine, and include such things as whether little Endian or big Endian format is used for storing compiled instructions, and the length of an instruction once it is compiled. Because these machine-dependent details are not reflected in the compiled code, the code can be transported to a different environment (a different hardware machine, a different operating system, etc.), and executed in that environment without requiring the code to be changed or recompiledxe2x80x94hence the phrase xe2x80x9cwrite once, run anywherexe2x80x9d. The compiled code, referred to as Java xe2x80x9cbytecodexe2x80x9d, then runs on top of a JVM, where the JVM is tailored to that specific operating environment. As an example of this tailoring of the JVM, if the bytecode is created using little Endian format but is to run on a microprocessor expecting big Endian, then the JVM would be responsible for converting the instructions from the bytecode before passing them to the microprocessor.
Programs written in Java take two forms: applications and applets. Java applets are applications that are intended to be downloaded to a user""s machine with a Web page, and run within the Web browser that displays the Web page. Since Java was introduced in 1995, it has gone through a number of dramatic changes in a very short period of time. During this evolution, number of advantages and disadvantages of using applications versus applets have come to light.
One of the areas of difference between applications and applets is in the Java runtime environment, as well as the affect of changes thereto. (The runtime environment includes the JVM, as well as a number of files and classes that are required to run Java application or applets. Hereinafter, the terms xe2x80x9cJVMxe2x80x9d and xe2x80x9cruntime environmentxe2x80x9d will be used interchangeably unless otherwise noted.) For applets, only a single level of the JVM exists in a given version of a browser. In order to upgrade the JVM level to keep pace with changes to the language, a new version of the browser must be installed. And, as new levels of browsers are installed on client machines, developers must update and maintain the Java code, recompiling (and retesting) it to match the browser""s JVM level. In addition, evolution of the Java language has in some cases resulted in functionality (such as specific application programming interfaces, or xe2x80x9cAPIsxe2x80x9d) being deprecated between Java levels. This means that applets written in Java version 1.0.2, while they work in Java version 1.1, may not work when the browsers adopt the next version, Java 2. To continue using an applet written in an older Java version without changing the applet, an older JVM level (and therefore an older browser) must be used. While this approach solves the problem of running applets written in older Java versions, it typically does not enable deployment of new applets within this browser, because development tools typically cease supporting generation of code in the older levels. Furthermore, as defects in existing browser JVMs are identified, applet developers often create work-arounds while waiting for JVM developers to fix the problem. Once the fixes are applied, the work-arounds may cause defects in the applet. In addition, obtaining the latest release of a browser does not necessarily imply that it will provide the latest release of the JVM level, as the level of JVM within a browser tends to lag behind the currently released JVM level by 6 to 8 months. This may mean that applets under development, which will be created using a development toolkit, are created using a newer JVM level than is available in the new browser.
For applications, changes to the run-time environment are easier to deal with, as most Java applications ship bundled together with their own level of the Java runtime and those that don""t state the required level of the Java runtime. However, shipping a runtime with the application means that multiple copies of the same JVM level may be installed on the client, leading to wasted storage space. When the application is not bundled with its runtime, on the other hand, the user is responsible for making sure that the correct JVM level is installed and the application is set up to use that level. Changing the runtime level so that a Java program can run, and making sure that all system settings are appropriate for the new level, is a difficult task for an end user to perform in today""s environment. One solution to this problem is to write Java programs so that they will run correctly across multiple Java runtime levels. This, however, is a very difficult task for a developer, and is therefore not a viable solution.
A further issue in the run-time environment for applets is differences in how browsers from different vendors implement a particular JVM level. The browsers most commonly used today are Netscape Navigator and Internet Explorer. Because an applet developer typically has no way of predicting which browser (or browsers) will be used to run his application, good development practice calls for testing the applet with each potential browser. As will be readily apparent, the time spent testing an applet grows significantly when it is tested for multiple browsers, multiple JVM levels within each browser, etc. (as well as possibly testing implementations of the browsers on different operating system platforms). Sun Microsystems has attempted to address inter-browser differences (which also provides a way of making the latest run-time level available for applet execution) by providing a Java Plug-In which allows applets to be executed using a run-time environment provided by Sun, instead of the run-time provided by the browser. A JVM level can be selected from among those supported by the plug-in. However, this approach requires a user to understand which is the required JVM level and how to select it. In addition, the plug-in still provides a single level of a JVM until the user manually selects a different level, and therefore does not address the problems discussed above related to differences between JVM levels.
For applications, differences in JVM implementations manifest themselves differently. Typically, there is only one version of each JVM level per operating system platform. It may be easier for a developer to predict which operating system his applications will run on than it is to predict which browser will be used for executing applets. Thus, the test and support requirements are significantly simpler for applications than for applets. Synchronization between the JVM level used in application development and the JVM level used for executing the resulting application, as well as the synchronization problems related to fixing errors, are less likely to present a problem, compared to the situation for applets that was discussed above. This is because both the development and runtime environment for applications are likely to be provided by the same vendor. In addition, when it is desirable to run an application on an older JVM (for example, due to changes such as function being deprecated, as previously discussed), this is less troublesome for an application than for an applet. The only requirement with the application scenario is that the older JVM is still available.
Another significant difference between applications and applets is their ease of use for end-users. Java-enabled browsers make it very easy for a user to run Java applets, where the user is required to do nothing more for execution than pointing the browser at the applet and clicking on a button. The user needs to know very little about the Java language and applets, and may not even realize that an applet is being invoked. Therefore, users do not need to be trained in how to run Java applets, saving time and money. Running a Java application (i.e. running a Java program outside a browser), on the other hand, is considerably more complicated. A Java application can be run from a development toolkit such as the JDK (Java Development Kit) product from Sun Microsystems; alternatively, the application may be run using the xe2x80x9cJRExe2x80x9d (Java Runtime Environment) product (hereinafter, xe2x80x9cJRExe2x80x9d), also from Sun Microsystems. The JRE is a subset of the JDK, providing the functionality which is required for application execution. Programs are executed from the command line when using the JRE. Running an application in either the JDK or JRE requires a fair amount of knowledge about the Java language and its environment. For example, the linked library paths and classpath environment variable must be properly set, and may change for each different application program. A number of dependencies may exist for running a particular application. For example, if the application makes use of a Java extension such as the Swing user interface components, the Swing libraries must be available. If the code for the extensions is not already installed on a user""s machine, it may be difficult for an average user to locate the code and then perform a proper installation (i.e. including setting all the required variables to enable the class loader to find the code at run-time). In addition, a user must understand how to operate the JDK or JRE for program execution. While Java developers and system administrators may readily understand these types of information, it is not reasonable to place this burden on the average end-user who simply wants to execute a program.
Several problems related to differences between browser implementations have been discussed. Two additional problems are differences in support for security features, and differences in archive formats. Security features are used in an applet by invoking the security APIs provided by the browser. The primary browsers in use today have different security APIs. This forces an applet developer to write (and test) security code that is different between the browsers, increasing the cost of providing the applet code. While the xe2x80x9cCABxe2x80x9d (for xe2x80x9ccabinetxe2x80x9d) file format is used for distributing and archiving files for the Internet Explorer browser, xe2x80x9cJARxe2x80x9d (for xe2x80x9cJava archivexe2x80x9d) file format is used to distribute and archive Java applet files.
Accordingly, a need exists for a technique by which these shortcomings in the current Java environment can be overcome. Ideally, the advantages of applets and the advantages of applications should be combined, providing an environment which then avoids the disadvantages of each. The present invention defines a novel approach to solving these problems, which will result in programs that are easier to use, and less costly to provide.
An object of the present invention is to provide a technique whereby shortcomings in the current Java environment can be overcome.
Another object of the present invention is to provide a technique whereby the advantages of applets and the advantages of applications are combined, providing an environment which then avoids the disadvantages of each.
It is another object of the present invention to provide a technique that enables dynamically switching among run-time environments for Java programs, on a per-program basis.
It is yet another object of the present invention to provide this technique in a manner that enables a user to easily switch between different run-time environments.
A further object of the present invention to provide a technique for specifying the dependencies of a Java application, including which run-time environment is required.
Yet another object of the present invention to provide this technique in a manner that enables the dependencies to be located automatically, and downloaded and installed, without requiring a static specification of location information.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer-readable code for use in a computing environment capable of having a connection to a network, for improving the manageability and usability of a Java environment. This technique comprises: defining a plurality of properties for a Java application, wherein the properties describe the application, zero or more extensions required for executing the application, and a run-time environment required for executing the application; and storing the defined properties along with an identification of the application. This technique may further comprise installing the application on a client machine using the stored properties. Preferably, installing the application further comprises: installing one or more dependencies of the application, wherein the dependencies comprise the required extensions and the required run-time environment; and installing a Java Archive file for the application on the client machine, and this installing dependencies further comprises: parsing the properties to locate the dependencies; determining whether each of the dependencies are already installed on the client machine; and retrieving and installing the located dependency when it is not already installed. Optionally, the technique may further comprise retrieving a latest version of the stored properties for the application prior to operation of installing the one or more dependencies. The installing one or more dependencies may further comprise dynamically retrieving a location for use in said retrieving and installing. In one aspect, the technique may further comprise creating a registry file on the client machine corresponding to the properties. In this aspect, the technique preferably further comprises: receiving a request to execute a selected application on the client machine; constructing a proper run-time environment for the selected application using a corresponding registry file; and starting execution of the selected application in the constructed environment. The constructing may further comprise: reading the corresponding registry file to determine current dependencies of the application, wherein the current dependencies comprise currently-required extensions and a current run-time environment for the application; ensuring that each of the current dependencies of the selected application is installed; setting appropriate environment variables for the current run-time environment; and setting appropriate environment variables for the currently-required extensions. Optionally, the technique may further comprise: updating the current run-time environment in the registry file; and updating the currently-required extensions in the registry file. In addition, the technique may further comprise setting one or more parameters of the selected application using the corresponding registry file, and may provide for updating the parameters in the registry file.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.